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ABSTRACT 


Is  It  possible  to  build  a  message  processing  system  that  not  only 
provides  the  user  with  a  clean  usable  Interface  but  Is  also  multi¬ 
level  secure?  To  answer  that  question  the  Defense  Advanced  Research 
Projects  Agency  and  the  Navy  specified  both  of  these  as  requirements 
In  their  test  of  a  military  message  processing  system.  We  believe 
that  the  SIGMA  message  service  built  by  Information  Sciences  Institute 
provides  both. 

This  paper  presents  the  security  design  of  SIGMA,  which  Includes: 
a  description  of  the  user  interface  to  security,  a  description  of 
how  SIGMA  provides  that  Interface  securely,  and  a  description  of  what 
a  security  kernel  must  provide  In  order  to  support  SIGMA  efficiently. 
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SECTION  I 


INTRODUCTION 


'v 

The  Department  of  Defense  Advanced  Research  Projects  Agency 
(DARPA)  and  the  Navy  are  currently  conducting  an  experiment  to 
evaluate  the  operational  use  and  organizational  Impact  of  a  computer- 
aided  message  handling  system.  An  Important  aspect  of  this  ex¬ 
periment  was  to  design  a  system  with  sufficient  security  controls  to 
enable  It  to  process  messages  at  multiple  levels  of  classification. 

An  equally  Important  aspect  of  the  experiment  was  for  the  system  to 
exhibit  a  rich  user  Interface  that  was  Judged  easy  to  learn  and  use. 
Herein  we  present  the  security  aspects  of  the  design  for  the  SIGMA 
Message  Processing  System,  the  system  chosen  for  the  experiment 

fir  bherl allowing  section,  a  description  of  the  SIGMA  Message 
Processing  System  Is  given.  Section -!«'  provides  background  and 
discusses  the  kernel  approach  to  multilevel  security.  -W^  describe 
In  Section  -IV,  several  security  problems  encountered  In  the  design. 
Section  V  presents  the  design  of  the  SIGMA  message  service.  The 
additional  features  that  the  kernel  must  provide  to  support  SIGMA 
efficiently  are  documented  In  Section  VI.,  Finally,  a  summary  Is 
provided  to  highlight  the  paper's  main  points. 


The  SIGMA  message  service  Is  one  of  three  services  developed 
during  this  experiment.  The  other  two  are  the  HERMES  system 
built  by  Bolt,  Beranek  and  Newman,  Inc.  [l]  and  DMS  built  by 
Massachusetts  Institute  of  Technology  [2J. 
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SECTION  II 


THE  SIGMA  MESSAGE  PROCESSING  SYSTEM 


Information  Sciences  Institute  of  the  University  of  Southern 
California  developed  SIGMA  specifically  to  meet  the  message  handling 
needs  of  a  military  command.  SIGMA  Is  a  secure  Interactive  message 
handling  system  providing  computer-aided  message  handling  services 
for  the  receipt,  filing,  retrieval,  creation,  and  coordination  of 
military  (AUTODIN)  messages.  We  consider  it  secure  in  that  it  pre¬ 
sents  an  Interface  to  the  user  constrained  to  abide  by  the  DoD 
security  policy.  It  Is  an  Interactive  system  since  all  user-system 
communications  occur  via  an  on-line  terminal  with  a  CRT  display. 
Finally,  It  Is  a  message  handling  system  because  It  supports  the 
typical  message  processing  functions  needed  by  any  formal  organiza¬ 
tion's  operation. 

SIGMA  supports  the  full  cycle  for  processing  Incoming  and  out¬ 
going  messages  In  a  military  operation.  It  provides  flexible  filing 
capabilities  for  on-line  storage  of  all  messages.  Easy  access  to 
messages  and  files  Is  provided  by  selective  search  and  retrieval 
functions.  Incoming  AUTODIN  messages  move  through  the  system  by 
Informal  forwarding  or  by  formal  action  assignment.  Outgoing 
messages  are  processed  by  a  set  of  functions  supporting  message 
creation,  editing,  coordination,  release,  and  post-transmission 
comeback  copies. 

SIGMA  operates  on  a  DEC  PDP-10  computer  with  the  TENEX  opera¬ 
ting  system.  AUTODIN  messages  enter  through  the  local  AUTODIN 
message  exchange.  SIGMA  distributes  these  messages  to  all  pertinent 
addressees  on  the  system  where  each  user  can  access  them  through  his 
SIGMA  display  terminal. 
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SECTION  III 


THE  KERNEL  APPROACH  TO  MULTILEVEL  SECURITY 


The  need  to  process  multiple  levels  of  classified  data  led  the 
Air  Force  Electronic  Systems  Division  to  sponsor  several  research 
and  development  efforts  to  build  an  operating  system  that  could 
satisfy  by  technical  verification  that  DoD  security  requirements 
had  been  met  [3].  Many  of  the  results  of  the  ESD  work  have  been 
borrowed  In  the  design  of  SIGMA,  specifically  adherence  to  a  mathe¬ 
matical  model  based  on  the  concept  of  a  reference  monitor — an  ab¬ 
stract  mechanism  that  controls  the  flow  of  Information  within  a 
computer  system  by  mediating  every  attempt  by  a  subject  (active 
system  element)  to  access  an  object  (Information  container) . (2)  [4I 
The  hardware/software  mechanism  that  Implements  the  reference  monitor 
Is  called  a  security  kernel.  The  kernel  uses  the  rules  of  the 
mathematical  model  [s]  [b]  as  a  specific  policy  for  mediating  access 
requests.  This  Incorporation  of  policy  into  the  kernel  allows  for 
a  proof  that  verifies  that  the  kernel  correctly  applies  the  policy 
to  the  Information  it  protects.  [?]  [8] 

The  mathematical  model  establishes  an  "inductive  nature"  of 
security  by  demonstrating  that  security  is  preserved  from  one  state 
to  another.  Security  Is  defined  with  two  rules:  the  simple  security 
condition  and  the  *-property  [9].  The  former  states  that  a  subject 
(active  entity)  cannot  observe  the  contents  of  an  object  (liiformatlon 
container)  unless  Its  security  level  Is  greater  than  or  equal  to 
the  security  level  of  the  object. (3)  xhe  latter  further  restricts 
possible  access  by  stipulating  that  a  subject  may  only  modify  an 
object  if  that  object's  security  level  is  greater  than  or  equal  to 
the  security  level  of  the  subject. 


(2) 

In  a  computer  system,  subjects  are  users  and  processors,  and 
objects  Include  programs,  data  files,  and  peripheral  devices. 

(3) 

Currently  the  security  levels  used  in  SIGMA  are  only  the  four 
standard  DoD  classifications,  l.e..  Unclassified,  Confidential, 
Secret,  and  Top  Secret. 


The  purpose  of  the  simple  security  condition  is  to  prohibit 
users  from  obtaining  data  that  they  are  not  entitled  to  see.  The 
*-property  is  designed  to  prohibit  a  program  operating  on  behalf  of 
a  user  from  reducing  the  classification  of  any  information. 

When  a  user  is  given  a  clearance,  he  is  charged  with  responsi¬ 
bility  for  maintaining  the  classification  of  classified  information. 

A  computer  utility  cannot  necessarily  be  given  this  same  trust. 

This  is  due  to:  the  amount  of  information  that  may  be  compromised; 
the  speed  with  which  the  compromise  may  occur;  and  the  difficulty 
in  detecting  or  apprehending  the  violating  program.  By  enforcing 
the  *-property  on  computer  programs,  a  program  will  not  be  able  to 
either  accidentally  or  maliciously  compromise  information.  Designers 
of  computer  utilities  constrained  by  the  *-property  must  ensure  that 
*-property  enforcement  does  not  unnecessarily  restrict  the  capabil¬ 
ities  of  the  user. 

The  enforcement  of  the  *-property  allows  us  to  reduce  the 
volume  of  code  that  needs  to  be  trusted  to  a  central  section  of  the 
operating  system.  This  central  section  of  the  operating  system  is 
the  software  component  of  the  security  kernel.  To  provide  security, 
a  kernel  must  1)  mediate  every  access  by  a  subject  to  an  object, 

2)  be  protected  from  unauthorized  modification,  and  3)  correctly 
perform  its  functions.  A  kernel  satisfies  the  first  requirement  by 
creating  an  environment  within  which  all  non-kernel  software  is 
constrained  to  operate  and  by  maintaining  control  over  it. 

The  requirement  to  protect  against  unauthorized  modification  is 
satisfied  by  isolating  the  security  kernel  software  in  one  or  more 
protection  domains,  for  example,  by  a  ring  mechanism  [lO].  Finally, 
the  requirement  that  the  kernel  correctly  perform  its  functions  is 
satisfied  by  using  a  formal  methodology.  A  suitable  methodology 
was  Introduced  by  Bell  and  Burke  [7].  It  Includes:  1)  a  proof  that 
the  kernel  behavior  enforces  the  desired  policy  [ll] ;  and  2)  a  proof 
that  the  kernel  is  correctly  implemented  with  respect  to  the  des¬ 
cription  of  its  behavior  used  in  the  first  step  [l2]. 

We  designed  SIGMA  with  security  kernel  technology  in  mind._ 
However,  due  to  the  absence  of  a  kernel  on  the  PDP-10  (the  machine 
we  used),  the  current  implementation  was  done  without  a  kernel.  We 
have  rigorously  scrutinized  the  SIGMA  design  to  ensure  that  the  user 
interface  provided  would  remain  unchanged  should  SIGMA  be  reimple¬ 
mented  on  a  security  kernel.  In  addition,  the  security  primitives 
have  been  evaluated  to  ensure  that  their  usefulness  warrants  their 
being  Included  in  a  kernel. 


SECTION  IV 


SECURITY  PROBLEMS  OF  MESSAGE  PROCESSING  SYSTEMS 


A  kernel  supporting  the  current  mathematical  model  of  the  DoD 
security  policy  Is  well  suited  for  certain  environments,  such  as  a 
programming  environment  In  which  users  operate  at  a  single  security 
level  for  long  periods  of  time.  [l3]  A  message  processing  environ¬ 
ment  presents  several  problems  not  found  In  previous  environments. 
Including  1)  the  dynamic  nature  of  the  user's  "working  security 
level";  2)  the  desire  to  present  to  the  user  Information  at  more 
than  a  single  security  level;  3)  the  desire  to  accurately  Inform 
the  user  of  the  security  level  of  all  Information  he  Is  reading  or 
writing;  and  A)  the  ability  of  users  to  extract  text  Information 
and  place  It  In  a  message  of  a  lower  classification  then  the  source. 

The  user's  "working  security  level"  In  a  message  system  en¬ 
vironment  Is  considerably  more  dynamic  than  In  the  programming  en¬ 
vironment.  Each  time  that  a  user  performs  an  action  on  a. different 
message,  his  working  security  level  may  have  to  change;  for  example, 
a  user  reading  a  Secret  message  may  generate  an  Unclassified  reply. 
While  we  could  require  the  user  to  process  messages  at  a  single 
security  level  at  a  time,  the  resulting  user  Interface  would  be 
clearly  unacceptable  to  the  user.  [lA] 

To  deal  with  these  problems  a  new  approach  Is  needed  that  In¬ 
cludes:  a  terminal  that  will  allow  users  to  process  Information  at 
more  than  one  security  level  at  a  time;  and  trusted  processes  that 
are  able  to  violate  the  security  rules  In  a  controlled  manner.  The 
next  section  describes  the  security  architecture  of  the  SIGMA 
message  processing  system. 
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SECTION  V 


SECURE  MESSAGE  PROCESSING  SYSTEM  ARCHITECTURE 


The  SIGMA  security  design  has  two  goals:  to  produce  a  certlflably 
secure  service,  and  to  present  the  user  with  an  agreeable  user  Inter¬ 
face.  In  many  situations  these  goals  are  at  cross-purposes.  Our 
general  approach  has  been  to  present  the  user  with  a  true  picture  of 
what  Is  happening,  maintain  the  user's  data  at  the  proper  level  (or 
higher  If  this  Is  not  possible),  and  make  It  convenient  for  the  user 
to  do  the  right  thing.  [IA] 


OVERVIEW  OF  THE  DESIGN 

When  using  SIGMA,  a  user  is  actually  interacting  with  a  collection 
of  up  to  five  processes  (see  Figure  1).  These  are  the  trusted  pro¬ 
cess,  an  unclassified  control  process,  and  one  process  for  each 
classified  level  that  the  user/terminal  Is  cleared  to  operate.  Each 
process  (except  the  trusted  process)  can  write  data  only  at  it£»-  own 
level  and  can  read  data  at  its  level  or  lower. 

SIGMA  attempts  to  be  as  helpful  to  the  user  as  It  can,  organizing 
the  user's  session  and  cleaning  up  the  user's  state  (current  context) 
as  necessary.  The  service  also  attempts  to  understand  the  user’s 
current  context  and  conform  Its  behavior  to  the  situation.  For  this 
reason  the  context  information  must  be  available  to  all  user  pro¬ 
cesses;  thus.  It  must  be  unclassified. 

The  user's  state  in  SIGMA  is  divided  into  two  parts.  The  first 
part  contains  the  current  list  of  objects  being  accessed  and  functions 
being  performed  by  the  user.  This  portion  of  the  state  Is  maintained 
at  the  unclassified  level  by  the  unclassified  control  process.  The 
second  part  contains  the  current  list  of  message  entries  (from  the 
open  message  file)  In  which  the  user  has  expressed  an  Interest.  The 
entry  list  information  is  potentially  classified  at  the  level  of  the 
file  and  Is  thus  maintained  at  this  classification  level  by  the 
appropriate  classified  process. 

This  dichotomy  of  state  is  reflected  directly  into  the  security 
design.  Commands  are  divided  into  those  which  access  the  unclassified 
state  (unclassified  commands)  and  those  which  access  the  entry  list 
(classified  commands).  The  latter  group  Includes  both  commands  that 
use  the  entry  list  for  input  and  those  that  allow  the  user  to  enter 
classified  Information  as  part  of  the  command. 
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Figure  1.  Sigma  Process  Structure 


MULTILEVEL  TERMINAL 


We  designed  the  terminal,  used  by  SIOIA,  to  enable  the  user  to 
Interact  with  data  at  more  than  one  security  level  at  a  time.  The 
screen  of  this  "multilevel  terminal"  Is  divided  Into  "windows"  (see 
Figure  2),  each  of  which  Is  logically  an  Independent  terminal.  Each 
window  scrolls  Independently  and  may  have  a  different  security  level. 
Windows  are  further  divided  Into  domains  that  have  various  attributes 
(e.g.,  enterable,  editable,  underlined,  etc.).  The  domain's  se¬ 
curity  level  Is  the  same  as  that  of  the  window. 

To  keep  the  user  appraised  of  the  level  of  Information  he  Is 
viewing  and  entering,  we  added  two  sets  of  lights  to  the  terminal. 
Each  set  consists  of  four  lights  (one  for  each  security  level);  one 
and  only  one  light  of  each  set  Is  on  at  any  time.  The  first  set  Is 
mounted  on  the  keyboard;  It  specifies  the  classification  of  the 
window  In  which  the  cursor  currently  resides .  If  the  user  wishes 
to  know  the  level  of  any  particular  piece  of  Information  on  the 
screen,  he  may  move  his  cursor  to  the  Information.  The  second  set 
of  lights  Is  mounted  next  to  the  screen  and  specifies  the  maximum 
level  of  Information  displayed  on  the  screen. 


FORM  OF  COMMAND  INPUT 

We  designed  command  Input  so  that  It  could  be  done  through  a 
separate  window  that  Is  normally  at  the  unclassified  level  In  order 
to  keep  the  majority  of  the  user's  state  Information  at  unclassified. 
Certain  commands,  such  as  the  "find  text  string"  command,  have 
potentially  classified  arguments.  For  these  commands  the  security 
level  of  the  command  window  Is  raised  to  the  level  of  the  object 
that  the  command  Is  affecting  before  the  user  enters  the  parameters. 

Strict  enforcement  of  the  security  model  eliminates  any 
possibility  of  a  security  compromise:  a  write-down  path  through  the 
system  that  could  be  used  to  release  Information  of  a  higher  security 
level  to  a  lower  security  level.  [l5;  However,  even  with  the  en¬ 
forcement  of  the  model,  there  are  several  situations  In  a  message 
system  where  the  user,  by  following  Instructions  given  by  the  system, 
can  Inadvertently  compromise  small  amounts  of  Information. 

Consider  the  following  example:  A  user  asks  for  a  list  of  all 
his  messages  with  a  subject  having  word  "x"  In  them.  To  perform 
this  operation,  the  user  must  be  at  the  security  level  of  the  file 
that  he  Is  looking  at — greater  than  or  equal  to  the  security  level 
of  all  the  messages  within  that  file.  The  enforcement  of  the  *- 
property  forces  the  result  of  this  examination  to  be  at  the  level 
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at  which  the  examination  was  performed — the  security  level  of  the 
file.  Should  the  user  then  decide  to  perform  any  modification  to 
a  message  returned  by  this  examination  that  has  a  security  level 
lower  than  the  file  security  level,  the  *-property  would  require 
him  to;  issue  commands  at  the  security  level  of  the  message  that  he 
desired  to  modify,  and  tell  the  system  the  unique  identification 
of  the  message  told  to  him  by  the  classified  process.  (The  unique 
Identification  is  required  here  because  the  system  is  unable  to 
pass  the  desired  identifier  "down"  due  to  the  enforcement  of  the 
*-property.)  However,  this  transmission  through  the  user  of  the 
message-id  from  the  higher  process  to  the  lower  process  is.  Itself, 
a  violation  of  the  *-property.  Although  it  is  conceivable  that  a 
maliciously  written  program  could  use  this  *-property  violation  to 
compromise  Information,  we  assume  that  the  user  serves  as  an  effec¬ 
tive  filter  in  this  write-down  path  (both  in  "bandwidth"  and  in 
checking  for  reasonableness),  thereby  precluding  any  reasonable 
software  means  of  making  use  of  this  path. 

Because  of  the  hardships  that  strict  enforcement  of  the  *- 
property  imposes  on  the  user  and  because  of  the  existence  of  *- 
property  violations,  a  case  can  be  made  to  ease  the  user  Interface 
in  situations  where  this  type  of  violation  exists.  The  Improvement 
takes  the  form  of  allowing  SIGMA,  in  violation  of  the  *-property 
rule  of  the  security  model,  but  with  user  concurrence,  to  write¬ 
down  the  unique  identifier  of  the  message  that  the  user  wants  to 
modify.  We  limit  the  bandwidth  of  this  type  of  *-property  violation, 
so  that  it  is  no  larger  than  the  path  that  otherwise  occurs  through 
actions  of  the  user,  by  allowing  only  a  specific  amount  of  fixed- 
format  information  to  be  transmitted  to  a  lower  security  level  and 
then  only  if  the  user  has  depressed  an  appropriate  function  key  that 
is  linked  directly  to  the  security  kernel.  Allowing  the  system  to 
transmit  this  information  greatly  simplifies  the  user  Interface. 


TRUSTED  PROCESS  FUNCTIONS 

Certain  functions  need  special  capabilities  to  operate  (such 
as  the  passing  of  message  identifiers)  but  are  relatively  message- 
system  dependent  and  thus  are  not  Included  in  the  security  kernel. 
We  group  these  functions  together  in  a  "trusted  process"  that  has 
the  ability  to  transfer  Information  in  a  controlled  fashion  in 
violation  of  the  *-property. 

The  trusted  process  in  SIGMA  performs  four  functions:  change 
classification;  message  release;  command  completion  signals;  and 
entry  list  transmission. 


ID 


SIGMA  allows  users  to  change  the  classification  of  text  that 
they  are  allowed  to  access.  When  this  happens,  the  trusted  process 
clears  the  screen  and  presents  the  text  in  a  simple  fashion  (19 
lines  at  a  time)  for  confirmation.  When  the  user  has  confirmed  the 
entire  object,  the  trusted  process  logs  this  action  and  passes  the 
text  to  a  process  at  the  new  security  level  for  refiling. 


Message  Release 


In  the  military,  formal  messages  are  released  with  the 
commander's  signature,  or  the  signature  of  his  designee.  Therefore, 
we  consider  the  act  of  releasing  a  message  a  security  event.  To  con¬ 
trol  message  release,  we  require  that  the  trusted  process  Insure  that 
the  user  requesting  the  release  is  authorized  to  release  and  that 
this  user  is  making  the  request  from  an  authorized  terminal. 


An  additional  security  consideration  with  message  release  is 
that  some  AUTODIM  terminals  (ours  in  particular)  treat  the  message 
header  as  unclassified.  In  SIGMA  this  header  is  created  in  the 
same  window  as  the  message  text.  Therefore,  releasing  a  message 
implicitly  lowers  the  classification  of  the  header  information. 
During  message  release  the  trusted  process  requires  the  user  to 
confirm  that  all  of  the  header  information  is  actually  unclassified. 
The  trusted  process  logs  this  action  before  releasing  the  message. 


Command  Completion  Signals 


We  have  based  the  SIGMA  design  on  the  concept  of  an  unclassified 
process  that  receives  the  majority  of  the  commands,  determines  the 
proper  security  level  needed  to  execute  these  commands,  and  then 
activates  a  process  at  that  security  level  to  perform,  the  execution. 
The  disadvantage  of  this  approach  is  that,  should  an  error  occur 
between  the  unclassified  control  process  and  the  classified  opera¬ 
tional  process,  the  classified  process  cannot  ask  for  clarification. 
Thus  error  recovery  is  difficult.  This  problem  is  referred  to  as 
the  open  loop  problem. 


Presently  we  believe  that  the  best  solution  to  the  open  loop 
problem  is  to  allow  the  trusted  process  to  close  the  loop  when  an 
error  of  this  type  is  encountered,  provided  the  user  has  depressed 
a  function  key  since  the  last  such  request.  Closing  the  loop  im¬ 
proves  recovery  but  has  an  Impact  on  security,  since  a  *-property 
violation  exists  when  the  loop  is  closed.  As  in  command  input, 
requiring  a  user  action  between  successive  writedowns  restricts  the 
bandwidth  of  this  operation. 


11 


Entry  Lists 


When  a  user  process  needs  to  write  down  a  list  of  message 
identifiers,  "entry  lists".  It  passes  this  list  to  the  trusted 
process  for  user  confirmation  directly.  The  trusted  process  checks 
the  format  and  bounds  of  the  entry  numbers,  and  asks  the  user  to 
directly  confirm  the  number  of  entries  being  processed  at  each 
security  level.  Thus,  the  user  has  the  ability  to  directly  monitor 
(and  control)  the  bandwidth  of  the  writedown  channel.  This 
separate  step  Is  reasonable  even  from  the  user  Interface  side,  for 
If  the  number  is  too  high  or  too  Iqw.  the  user  can  see  that  he 
specified  his  request  incorrectly.^^' 


(4) 

If  the  entry  list  has  only  one  element,  then  the  appropriate 
function  key  Is  sufficient  and  the  further  "confirm  1  entry" 
step  Is  omitted.  This  operation  allows  the  user  to  point  to  a 
single  entry  or  mention  It  by  number  or  context  (CURRENT,  NEXT) 
for  a  display,  reply,  file,  etc.,  without  being  required  to  do 
more  than  use  the  proper  function  key  to  enter  or  confirm  the 
command . 
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SECTION  VI 


KERNEL  REQUIREMENTS 


In  order  to  be  able  to  support  the  SIGMA  architecture,  the 
security  kernel  must  provide  certain  additional  features  not  found 
In  kernels  designed  to  date.  Including  a  terminal  multiplexor  for 
the  multilevel  terminal,  a  variety  of  object  sizes,  the  ability  to 
support  large  numbers  of  processes,  an  efficient  Inter-process  com¬ 
munication  facility,  and  a  policy  that  can  support  "trusted"  pro¬ 
cesses. 


MULTILEVEL  TERMINAL  CERTIFICATION 

Since  the  terminal  supports  the  simultaneous  display  and  editing 
of  data  at  different  classifications,  we  must  demonstrate  that  the 
terminal  1)  maintains  the  proper  levels  for  all  Information  It  con¬ 
tains  (possibly  20,000  characters)  and  2)  marks  all  Information  re¬ 
turned  to  the  computer  with  the  proper  security  level.  It  Is  the 
terminal's  responsibility  to  assure  that  no  Information  entered  In 
a  window  by  either  the  user  (doing  local  editing)  or  the  application 
computer  Is  transferred  to  any  other  window.  While  at  first  pass 
the  certification  of  the  terminal  may  seem  trivial,  one  must  consider 
that  the  terminal  code  Is  currently  produced  for  a  single  INTEL  8080 
and  occupies  32K  bytes  of  PROM.  Eventually  multiple  8080* s,  appli¬ 
cation  of  Denning's  flow  control  [l6],  or  the  Introduction  of  a 
kernel  In  the  terminal  will  be  necessary  to  guarantee  separation  of 
the  windows. 


TERMINAL  MULTIPLEXOR 

A  significant  problem  Is  the  method  for  attaching  the  multilevel 
terminal  to  a  secure  system.  We  have  Identified  two  alternatives: 
each  window  could  have  a  unique  connection  to  the  system  or  the 
kernel  could  multiplex  all  Information  to  a  terminal  over  the  same 
communication  line.  We  have  chosen  the  multiplexing  approach  In 
order  to  minimize  the  number  of  terminal  lines. 
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Communication  between  the  system  and  the  terminal  Is  In  the 
form  of  NOTICES  dnd  DISPATCHES. The  terminal  multiplexor  must 
assure  that  each  NOTICE  received  from  the  terminal  Is  directed  to 
a  user  process  whose  security  level  Is  the  same  as  the  security 
level  of  the  window.  The  multiplexor  must  also  forward  Function 
Key  Notices  to  the  trusted  process  to  provide  for  the  capability 
for  a  controlled  write-down  of  message  Identifiers. 

The  terminal  multiplexor  must  Insure  the  correctness  of  all 
DISPATCHES  to  the  terminal.  With  the  exception  of  "window  alloca¬ 
tion"  DISPATCHES,  the  terminal  multiplexor  need  only  check  the 
window  Identifier  and  length  to  assure  that  the  user  process  Is 
communicating  with  a  window  to  which  It  has  access.  All  requests 
for  terminal  window  allocations  and  deallocations  must  be  done  by 
the  unclassified  user  control  process.  This  process  provides  the 
terminal  multiplexor  with  the  security  level  for  all  newly  created 
windows.  The  unclassified  process  can,  at  a  later  time,  request  a 
change  In  a  window  classification  by  notifying  the  multiplexor.  If 
this  new  security  level  Is  lower  than  the  current  window  security 
level,  the  multiplexor  must  erase  the  Information  currently  In  the 
window. 


PROCESS  STRUCTURE 

The  design  of  the  kernel's  process  structure  will  have  signifi¬ 
cant  Implications  for  the  performance  of  SIGMA.  On  traditional 
timesharing  systems,  such  as  TENEX,  process  creation  Is  expensive, 
and  process  swapping  Is  lengthy.  In  order  for  SIGMA  to  operate 
efficiently  the  kernel  must  be  able  to  1)  support  large  number  of 
processes;  2)  allow  for  fast  process  creation  and  deletion;  and 
3)  swap  processes  with  little  overhead.  Large  numbers  of  processes 
are  required  because  SIGMA  requires  several  active  processes  per 
user.  If  SIGMA  Is  extended  to  handle  compartmented  Intelligence, 
fast  process  creation  and  deletion  would  be  required.  Finally, 
because  large  numbers  of  processes  are  doing  small  amounts  of  pro¬ 
cessing,  process  swapping  occurs  often.  To  expect  a  kernel  to  pro¬ 
vide  this  type  of  support  may  require  significant  hardware  support. 


(5) 


NOTICES  and  DISPATCHES  are  packets  of  Information  to  and  from 
the  host  computer  respectively. 
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INTERPROCESS  COMMUNICATION 


Equally  Important  to  the  efficient  operation  of  SIGMA  are  the 
speed  and  types  of  Interprocess  communication  provided  for  by  the 
kernel.  SIGMA  will  require  the  kernel  to  support  both  preemptive 
(Interrupt-llke)  and  non-preemptlve  (message- like)  types  of  inter¬ 
process  communication.  In  addition,  the  latter  mechanisms  must 
support  small  messages  for  passing  message-ids  and  large  messages 
for  transmitting  entire  command  strings. 


FILE  SYSTEM 

The  file  system  Is  often  one  of  the  most  complex  portions  of 
the  kernel,  a  quality  which  can  cause  unnecessary  overhead.  For 
example,  SI^IA  does  not  require  the  kernel  to  provide  a  file 
organization  such  as  a  directory  hierarchy.  A  "flat  file"  system 
Is  entirely  adequate  and  can  be  used  more  efficiently.  The  only 
special  requirements  for  SIGMA  are  that  the  kernel  should  support 
both  small  files  (512  bytes)  and  large  files  (lOK  bytes). 


SYSTEM  INTEGRITY  CONTROLS 

To  support  SIGMA  the  security  kernel  must  provide  a  mechanism 
that  Implements  the  notion  of  least  privilege.  This  mechanism  has 
been  given  the  name  "System  Integrity"  [l7].  SIGMA  uses  three 
separate  privileges:  a  secure  write-down  privilege  used  by  the 
trusted  process  to  reclassify  text;  a  release  privilege  used  to  re¬ 
strict  the  releasing  of  messages  to  a  select  group;  and  a  system 
security  officer  privilege  used  to  Initiate  and  set  the  security 
level  of  new  users. 

The  primary  rule  that  the  system  integrity  control  must  obey 
Is:  to  modify  an  object  or  execute  a  kernel  call  a  subject's  system 
Integrity  level  must  be  greater  than  or  equal  to  the  system  Integrity 
level  of  the  object  or  kernel  call,  [is]  There  are  no  rules  on 
reading  or  executing  programs  (programs  In  execution  use  the  system 
Integrity  level  of  the  process  that  they  are  executing  under).  We 
must  therefore  demonstrate  that  each  subsystem  with  a  system  Integ¬ 
rity  level  greater  than  system  low  (non-kernel,  no  privileges)  does 
not  execute  any  programs  other  than  ones  that  we  know  execute 
properly. 
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SECTION  VII 


SUMMARY 


The  design  of  SIGMA  demonstrates  that  It  Is  possible  to  build 
a  secure  message  processing  system  based  on  the  kernel  approach  to 
multilevel  security.  We  have  shown  the  refinements  to  the  approach 
that  are  needed  to  achieve  a  usable  Interface  and  have  dociunented 
the  features  that  a  security  kernel  must  provide  to  support  a  secure 
message  processing  system  efficiently.  The  techniques  used  in 
designing  SIGMA  should  be  directly  applicable  to  other  transaction- 
oriented  or  data  base  management  systems. 
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